iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 22
0
Mobile Development

30天,從0開始用Kotlin寫APP系列 第 22

Day 22 | Android 資料黃金三兄弟 - SharedPeference 、File 、SQLite

  • 分享至 

  • xImage
  •  

在 Android 中如果遇到需要長期把持的資料,會有三種方案可以選擇

  • SharedPeference :適合簡單、清量的 key-value 資料,例如 用戶ID、上一次登入時間這種
  • File :適合儲存複雜的格式,例如圖片、文章等等
  • SQLite :相信各位對 SQL 應該多少都有一點了解,那 SQLite 是一種在手機裏面很常見的 SQL ,主打輕量,和一般 SQL 用法大同小異,適合儲存比較複雜的結構化資料,例如部門成員或是圖片的路徑等等

沒有說誰好誰爛,只有適不適合的問題,例如不會希望把比較複雜的結構化資料存在 SharedPeference ,而會希望用 SQL 或是 Json File 的方式處理掉

接下來就一一介紹

SharedPreference

SharedPreference 通常會存在 /data/data/[app packageName]/shared_prefs/ 之下

那他的優點有

  • xml檔案的儲存方式
  • key-value 結構
  • value 只會儲存小量的資料
  • 無法儲存太複雜的行別,支援型別有:Boolean、Float、Integer、Long、String
  • 每個 App 獨立擁有自己的 SharedPerferecne

File

File 的話就很直觀是檔案,不論是 圖片影片PDF下載的APK 等等,都會是以 File 的型式儲存

講到 File 的儲存就要補充一下 Android 的 Storage ,在 Android 下, Storage 也分為三種,分別是

  • Internal Storage
  • Primary External Storage
  • Secondary External Storage

Internal Storage

Internal Storage 是只要目前 App 能夠存取的區域,其他 App 或是使用者都不能直接接觸到的空間,路徑通常會是 data/data/[app packageName]

裏面會包含像是 App 的 ConfigSharedPreferenceSQLite 等等。因為這個空間每個 App 都會有一個,因此站在 Android OS 的角度,就不會劃分太多的空間給某個 App ,只會是比較重要的檔案才會存在這個空間裏面,其他比較大型的檔案就會希望存在 External Storage

另外因為這個空間只專屬給對應的 App 持有,因此當使用者把 App 刪掉時,這個空間裏面的資料自然就會跟著被回收掉

Primary External Storage

Primary External Storage 是 OS 從裝置的 Storage 劃分出來的一個區塊,專門儲存從 App 中產出的圖片、影片、音檔等等,在這個空間的檔案也是可以提供給其他程式做使用

例如拍照軟體會把照片存到相簿,而修圖軟體可以到相簿中取得照片修圖,修完的圖可以在存回相簿中,讓其他程式去取用

另外需要注意的一點是在 App 要使用 External Storage 的檔案時,需要先取得 External Storage Permission 才能夠存取喔

Secondary External Storage

因為手機以前的儲存空間都不大,因此人手一張 16G 的 SD 卡,才能在上學的時候偷偷聽音樂或看影片,那外接儲存空間都算是 Secondary External Storage, 目前很多手機容量越來越大再加上雲端空間就非常夠用,因此手機中也漸漸拿掉 SD card 插槽了( 時代的眼淚...

SQLite

可能有些人會想說資料不都可以打 API 送到後端的 Database 做處理嗎?幹嘛在放一套資料在手機裏面,這樣不會很佔空間嗎?

其實這樣的看法對也不對,的確如果只是把 App 都做一種資料呈獻的手段,那其實 App 本身不需要握有太多數據,需要在打 API 去拿或是打 API 把生成出來的資料傳回去即可,但畢竟有些 App 是要考慮到使用者隱私或是要做到離線模式都能夠使用的,例如有些通訊軟體即使在沒有網路的狀態下,還是能看到一部份過去的聊天紀錄,這些可能就會是透過 SQLite 的方式暫且儲存起來,並且如果使用者在離線狀態下持續的發送訊息,那麼這些訊息會先 hold 在 SQLite 裏面,等到連上網路的時候在跟後端 Server 做 Sync ,因此手機裡面有 SQLite 還是非常重要的

那麼 SQLite 主要的優點就如同以下列出來的

  • Android 內建支援,不需要安裝
  • 每個 App 都有自己的 SQLite ,不能互相存取,具有隔離性
  • 用法上和其他 Relational SQL Service 大同小異
  • 儲存結構化數據

但 SQLite 因為追求小而巧,因此有省略掉一些部份,造成令人詬病的問題,例如

  • 使用錯誤的 Column name 編寫了一個 SQL 查詢,但在編譯時無法發現,必須等到 Runtime 才會報錯
  • 如果 SQLite 的架構做了修改,那就要手動更新受影響的 SQL 資料
  • 需要使用大量樣板代碼( Boilerplate Code )在 SQL 和 POJO 之間進行轉換

因為以上的問題,因此 Google 在 I/O 2018 的時候發表 Andorid Jetpack 時,在 Jetpack 中推出了 Google 官方支援的 SQL ORM - Room ,Room 改正了幾項問題

  • 編譯時會驗證 SQL 是否正確
  • Room 將 SQLite 映射到 POJO ,而沒有使用樣板代碼
  • Room 支援 SQL Migration
  • 可以與 LiveData 、RxJava 等等強大的工具一起使用

看到這邊是不是很想要學 Room 了呢?

總結

總結一下今天的部份,今天是複習 Android 中三種資料儲存的方案,以及 Internal Storage 與 External Storage 的差別,並且在介紹 SQLite 的時候也順勢帶到了明天會介紹的 Room
那下面這張圖是 Google 給出的一張比較圖,幾乎所有上面提到的東西,這張圖都有概刮到,可以在看完上面在服用這張圖會更有感覺喔

如果內容有任何問題或錯誤,歡迎提出與指教

Reference


上一篇
Day 21 | Android Animator - 翻開一張海賊卡
下一篇
Day 23 | JetPack 與他的產物 - Room (Part 1)
系列文
30天,從0開始用Kotlin寫APP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言